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Chapter 1 


Lists 


1.1 Introduction 


The list is among the most generic of data structures. In your own life, you encounter lists on 
a regular basis — you may take a shopping list to the grocery store, or write down a list of 
integers to enter into a lottery drawing. In computer science, lists are just as useful, and the 
idea is basically the same, namely, that: 


1. there is a collection of elements that are all of the same type (grocery items, integers, etc.), 


2. they are stored in some particular order (i.e. there is a first item, a second item, and so 
on.), and 


3. it is possible to insert new elements into various positions in the list, and remove any 
element of the list. 


1.2 The List ADT 


1.2.1 The initial construction of the ADT 


A list can be described abstractly as simply a set of elements in a linear order. For example, 
the data values a1, a2, a3, and a, can be arranged in the following list: 


(az, a1, a2, a4) 


In this list, ag is the first element, a; is the second element, and so on. The order is 
important here; this is not just a random collection of elements, but an ordered collection of 
elements. Certainly, there are some applications of lists where this ordering might not matter 
(set membership, for example, with the list representing a set and the elements of the list being 
the elements that are in the set). However, in other applications, keeping values in the order 
listed will be of vital importance. 

The above view is an abstract view. Note that we have made no mention of how the data 
is stored, physically — we have only discussed the “mental picture” of what our data looks like. 
This is very important. If we view the list in this manner, and design a set of operations so that 
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it correctly works on this “mental picture”, then we can change implementations at will, and not 
affect the set of operations at all. If, on the other hand, we tie in the interface to a particular 
choice of implementation, our operation set will not translate well to a new implementation. 

So, given the above definition of a list, what operations might prove helpful? Well, it will be 
necessary to insert and remove elements from a list, certainly. Searching the list for an element 
might prove helpful, and being able to read various elements of the list and replace them with 
new elements could be considered basic operations. There are other operations that can be 
helpful as well; some of them are summarized below: 


CreateList(): Create a new list (presumably empty) 

Copy(): set one list to be a copy of another 

Clear(): Clear a list (remove all elements) 

Insert(X, ?): Insert the value X at a particular position in the list 
Remove(?): Remove the value at some particular position in the list 
Retrieve(?): Retrieve the value at a particular position in the list 
Update(X, 7): Replace the value at a particular position with X 
Find(X): Determine if the value X is in the list 

Length(): Return the length of the list 


The idea behind each of those operations should be straightforward enough. One thing that 
is still unclear, though, is: what is meant by ”particular position”? In the above pseudocode 
function headers, this “particular position” is represented by a question mark. We can’t use 
a question mark in actual code, though, so it is necessary to decide exactly how to refer to 
particular list positions. 

As an example, if we want to insert an element, we need to specify where we want to insert 
it. Just choosing to insert it is not enough because in that case there is no specification of 
where in the list the element should be placed — meaning we don’t know if we are inserting the 
new element at the beginning of the list, at the end, or somewhere in the middle. Likewise, to 
retrieve a value in the list, it is necessary to specify which value to retrieve — the first, or the 
fourth, or whichever particular location is being dealt with. 

We have two different ways to refer to this position. The first is to use the actual index of the 
element: ”insert after element 3”, ”retrieve element 6”, and so on. This is the approach taken 
by arrays; in an array, every element has a particular index associated with it, and elements are 
accessed via those index values. 

The second way to refer to a particular position in the list is to use some kind of “current” 
marker or “current” pointer. Then, our operation is simply assumed to work at that “current” 
spot in the list. For example, if our “current” element was marked as the third element in 
the list, and our retrieval function was designed to retrieve whatever the current element was, 
then we could simply call the retrieve function — with no parameters — and the retrieve function 
would return whatever the current element was, in this case the third element. If this is the 
method used to indicate list position, then it is also necessary to add some additional operations 
to our collection of operations. The goal of these functions would be to manipulate the “current 
position” marker — for example, to move it backwards one position, or to move it to the very 
end of the list. In particular, the following four functions might prove useful: 


Head(): make the very first element the current position 
Tail(): make the very last element the current position 
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IncrementCurrent(): move the current position forward one element 
DecrementCurrent(): move the current position backward one element 


So, which approach should be used? Well, it turns out that the difference between the first 
approach and the second is the major difference between the Array ADT and the List ADT. For 
that reason, from this point on we will assume the “current position marker” approach (and will 
simply call this marker by the name current). If you need to be able to access the collection 
of elements by index, it can be done simply by starting current at the beginning of the list, 
and then calling IncrementCurrent () enough times so that the proper element is the current. 
If you expect to need to access the elements by index very frequently, then it is likely that the 
Array ADT would be a better choice for your design than the List ADT would be. 


1.2.2 Specific ADT considerations 


It is important to realize that the set of operations above, and the particular way they are called 
(i.e. number and type of parameters), is not set in stone. The basic ideas will the the same no 
matter what List interface you use, but the details are often up to the ADT designer, and since 
each designer has different opinions about some of the fine points, each List interface can turn 
out slightly different. For example, one designer might find it important to have a Length() 
function; another may not. One designer might want Find(X) to return the element if it is 
located, and another might prefer that Find(X) simply return a true or false indicating if the 
element is in the list or not. This will be true for all the data structures we study. A particular 
ADT is not set in stone, and the details may vary a bit — though of course, some data structures 
have a more consistent set of operations than some other data structures have. 

For the most part, we are just going to make use of one particular set of operations and use 
those in our discussion of implementations, without further comment. However, two particular 
ADT decisions are worth some further discussion. 

The first is the Insert() function. Presumably, since we are inserting based on the location 
of current, the only parameter our insertion function needs is the actual value to be inserted. It 
is necessary, though to decide if we are inserting before the current position, or after the current 
position. In either case, we have a problem. If we choose to insert after the current position, 
then there is no way to insert an element as the first position in the list. This is because the 
first position is not “after” any other element. Likewise, if we choose to solve that problem by 
inserting before the current position, then we are prevented from inserting as the last element, 
because the last position is not “before” any other element. 

So, how can we solve this problem? Consider the following three possibilities: 


1. One solution is to have a general Insert (X), that would insert after the current position, 
for most insertions, and to have a second function, InsertAtHead(X), that would insert X 
as the first element of the list. This solution has the advantage of having a single, clearly 
defined insert for most situations, but the disadvantage is that we have a function that 
only exists to solve a special case, and this is not necessarily the best design. 


2. A second solution is to use a dummy position. The idea would be to have a position at 
the start of the list that isn’t really a list value, but that can serve as a place to put the 
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current pointer: 


(x a3, 41, 42, a4) 


The position x is not really a list element — a3 is still the first element — but it 7s possible 
for current to be position x instead of position 1, 2, 3 or some other “real” position. In 
this case, you can have a single Insert (X) function, and can insert as the first element 
of the list by placing the current pointer onto position z and then calling Insert (X). 
This solution works nicely from the standpoint of having a single Insert (X) function that 
works in all cases, but the downside is that you have this position for which functions like 
Retrieve() and Update(X) are not defined, and so in that case the programmer needs to 
be careful to not use those functions if current is on position x rather than somewhere 
else. 


3. A third solution is to eliminate the “before or after” choice altogether by replacing Insert (X) 
with two functions: InsertBefore(X) and InsertAfter(X). Both of these functions would 
work on any element in the list. This would result in “double-coverage” of most list posi- 
tions; you can insert into a position either by calling InsertAfter(X) on the value prior 
to the position, or by calling InsertBefore(X) on the value following the position. The 
advantage here is that both functions are quite general, and that we don’t have unde- 
fined positions as we do with the dummy space idea. However, the drawback here is that 
we don’t have a single insertion procedure, but rather, two. This means that a little 
more thought must go into things on the programmer’s end so that the proper function is 
selected. 


Our choice will be to go with the third option. However, when you eventually design your 
own list class, your decision might be completely different, and that’s fine. 

The second decision that we will take a closer look at is the design of the Remove() function. 
Specifically, we have two choices: 


1. Remove(), which will remove the element at the current position 
2. Remove(X), which will search for X and remove it 


Which is better? Well, the second function will always perform a search for X and will then 
remove it. What if, due to the way you’ve traversed the list, you already know you are at the 
position that is holding X? In this case, if you use the second function, you will search again for 
it anyway. 

On the other hand, the first function does not do a search. However, we do have the Find (X) 
function available to us. So, a call to Find(X), followed by a call to Remove(), would seem to 
be the equivalent of a single call to Remove(X). By that logic, then, we should go with the first 
version, because it gives the option of searching for X or not searching for X, wherease the second 
function forces that search upon us. 

Now, once we deal with issues beyond function selection, this may turn out to not be the 
case. Function call overhead might be high enough that calling two functions (Find(X) and 
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Remove()) would be worse than calling Remove(X), and so if we expect to do a search-and- 
remove very often, the second option might become the better choice. In addition, if for some 
reason removal requires a search-like procedure, then we could perhaps overlap the find-search 
with the remove-search in the second version, whereas the first version would force the two 
searches into two separate functions. So, efficiency considerations might later show Remove (X) 
to be a better choice (at least for a particular application). But, just evaluating things from 
an “operation” standpoint, we will go ahead and add a Remove() instead of a Remove(X), and 
therefore avoid the forced search. 

Again, just as with our insertion decision, you might disgree with this decision, and that’s 
fine. You’re stuck with it for this semester, but in later semesters you can write your own List 
class and at that point you can design the ADT as you see fit. Part of the point of this class 
is to give you the means to evaluate situations like this intelligently, and come to your own 
conclusions that you can justify. 


1.3. Implementing Lists 


Just as the ADT provides an interface, we must now consider how to implement that interface. 
What we will examine next are some implementations of the List interface. 

1.3.1 Contiguous Memory 

Storing the data in contiguous memory 


One way to store list values would be in consecutive locations in memory. This could be accom- 
plished by using an array. For example, the list (2, 6, 8, 7, 1) could be represented as: 


current size 


Al 26) 8471 3 5 
ko 22h: Ax 





























The current position variable would then just be a variable stored independently of the array. 
(We will also store the size of the list separately, rather than having to recalculate it every time 
we want to know what it is.) 


List functions in contiguous memory 


So, how can we use this array in the implementation of our functions? Let’s start with 
InsertAfter(X). Upon a call to InsertAfter(X), we want to place the element we pass in 
after the current element. The current position is 3. The value at the third position in the list 
is 8. So, a call to InsertAfter(9), for example, will insert the value 9 after the value 8 in the 
list. This results in the list (2, 6, 8, 9, 7, 1). 

If we have implemented our list as an array, what we will need to do is shift everything to 
the right of 8 over one place to the right, giving us an array with one more cell than the original 
array, and a space at one of those cells, namely, the cell after the current cell. You can insert 
your new value in that space. 
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usually, we make the 
recently inserted value 
the current value 


If you were instead calling InsertBefore(X), all that would change would be that the 
current value would shift over one position as well. In the picture above, this would result in 
creating the empty cell to the left of “8” rather than to the right of it. 

Next, consider the function IncrementCurrent(). All that needs to be done here is to move 
the “current pointer” to the next value. That is, whatever value is the current value now, the 
next value should be the current value instead. With our array implementation, this is only 
a matter of incrementing the “current” index. (With this, and the other functions, there are 
occasionally some special cases involved; the basics will be covered here, and you will see the 
special cases in the code you study.) 
































current Size 
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Remove() would have to work in a manner opposite that of Insert(). Calling Remove() 
will remove the value at the current index. The current index here is 5, so the value we want to 
remove is 7. By removing it, we leave a blank space, which we then fill in by shifting the values 
to the right of position 5 over to the left one space to fill in the array. 
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When Find(X) is called, and it becomes necessary to search for an element in the list, 
basically we have to traverse down the array until we locate the value X. We don’t know where 
that value is in the array, or if it is even in the array at all, so there is nothing we can do but 
search the array. 


Find (X) 
{ 


int i=1; // start counter at beginning of list 


// move forward as long as 


// a) you are not at the end of the array, and 
// b) the element you are inspecting is not X 
while ((i != sizet1) && (A[i] != X)) 

itt; 


e) 


// if your counter is off the end of the array, 
// then you did not find X 


if (i == size + 1) 

return 0; // 0 here indicates ‘‘not found’’ 
// otherwise, your counter i is such that A[i] == X 
else 
{ 


current = i; 
return 1; 
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Most of the other operations are relatively simple. We’re leaving out discussion of the code for 
the constructors, destructor, and mass edit (copy and clear) code, but you can look over that 
yourself in the given code files. 


Retrieve() -> return A[current] ; 
Update(X) -> A[current] = X; 
Length() -> return size; 
DecrementCurrent() -> current--; 
Head() -> current = 1; 

Tail() -> current = size; 


Analysis of contiguous memory lists 


Insert - whichever position we insert at, we must move every value to the right of that position 
one space to the right, in order to make space for the new element. In the worst case, we are 
inserting at the beginning of the array and must move every element to the right one space. 
Moving an element is an O(1) operation (one array read and one array write, both of which are 
constant time), and so if we have n elements to move, the total cost of movement, and hence 
the total worst-case cost of insertion, is O(n) 


That is the worst-case. What about the average case? On the average, we expect that we 
will not have to shift every element. So, what do we expect we will have to shift? We would 
expect to shift half the elements. We expect that the current index will be before the midpoint 
of the array half the time, and after the midpoint of the array half the time; hence the average 
location of the current index would be the midpoint of the array. This leads to an insertion cost 
of (n/2) * O(1), which is O(n/2). Unfortunately, this is equal to O(n) 

In terms of constant costs, we expect that the average insertion will take only half as long 
as the worst-case insertion. However, 1/2 is only a constant, so the two cases are the same cost 
as far as their order of growth is concerned. 


Remove - the analysis for this function is much the same as for Insert(). The difference 
is that we are moving elements to the left rather than the right. In the worst case, we remove 
the first element and must shift the rest of the elements to the left one cell, an O(n) total cost. 
In the average case, we expect to move half the elements, incurring an O(n/2) = O(n) average 
case cost. 


Find - with Find, we will start at the beginning of the array and move forward one step (an 
O(1) operation) until we find our value. Worst case: we search all n elements (i.e. to the end of 
the array), incurring an O(n) cost. Average case: We search to the midpoint (we expect to find 
our element in the first half of the array half of the time, and in the second half of the array 
half of the time). This gives us an O(n/2) = O(n) average case cost. 


Most of the other operations are all simple array reads or writes, or one-operation arithmetic, 
allocation, or deallocation, and hence are O(1). The exception would be any function that 
involves copying the List, as such a task would involve reading the elements one-by-one and 
would hence take O(n) time. 
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1.3.2 Linked Memory 
Storing the data in linked memory 


The other option for storing a list would be linked memory. With this approach, our various 
cells of memory are not allocated consecutively in memory, but rather, are allocated in random 
places in memory. As a result, it is not enough to just store the values themselves, because the 
values are scattered all over the place. We need some way of determing where the various values 
are located when we want to read them. Previously, the second value was right next to the first 
value. Now, the first value must explicitly tell us where to look for the second value by keeping 
a data value on the side that holds the memory address of the second value. 

What we will do, in other words, is create a structure called a Node. A node is generally a 
small data structure that contains a few data values and is used within the context of a larger 
data structure. In this case, our “few data values” will be the actual List element value, and a 
pointer — that is, each node will hold one List value, and will also contain a pointer that will 
hold the starting location of the next value. In this manner, we can “chain” nodes together, 
and have each node refer to the next in the list. Then, provided we know where the first node 
is located, we can traverse the list node-by-node down to the last node of the list. 

The following would be a picture of a node: 





element next 














element: name of field that stores our value 


next: name of pointer field 
Figure 1.1: A node 


And the following would be a picture of our previous list, (2, 6, 7, 8, 1), implemented using 
linked memory. Such an implementation is usually called a linked list. 


head current 







































































size 


It is helpful to note some of the features of this linked list. First, we need a head pointer to 
point to the front of the list; otherwise, we would have no idea where the first node of the list 
was located. We obtain the starting positions of the rest of the nodes from the nodes prior to 
them in the linked list, so we only need a separate variable to hold the address of the first node. 
Second, current here is a pointer, not an index. Finally, note that the last element of the list 
points to “nothing”. However, if we just let that pointer hold some random address we have 
no way of knowing that there is not another node at that random address. A traversal of this 
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list would simply try to access the node at that meaningless random address, and since there is 
no node there, we would get a run-time error when we ran our code. So, instead, we point the 
pointer to NULL, which in C++ is memory location 0. It is guaranteed that nothing is ever at 
memory location 0, and so whenever we read a pointer that holds the value 0, we know it points 
to nothing. Above, we have represented NULL by a box with a slash through it; in fact, the 
more common way to represent a pointer to NULL is to actually put a slash through the pointer 
box itself, as follows: 



























































head current 

\ 

y 

2 > 6 > 8 7 > 1 
_size 
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List functions in contiguous memory 


To see how to use linked memory to implement our List ADT functions, let’s use the same 
examples that we used for the contiguous implementation. 

First, consider the function InsertAfter (X). If you again make the call InsertAfter (9), 
so that you can insert the value 9 after the value 8 in the list above, in the case of linked memory 
what we need to do is create a new Node, place it in the linked list between the third and fourth 
nodes, and then store 9 in that node. 

This turns out to be a relatively straightforward operation, but care must be taken to do the 
steps in the right order. The first thing we need to do is allocate the new node. Since we will 
code Node to be a class, we can simply allocate a new code by declaring a local Node pointer 
and then pointing it to a dynamically allocated Node object, as follows: 





step 1: Node* temp; temp 

















step 2:temp = new Node(); temp| —}—s 

















Figure 1.2: Allocating a new node 
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This will give us a new node that we can then begin trying to connect to our list. Initially, 
however, it is not connected to the list at all, but simply floating off by itself, as follows: 

































































head current 
\ 
| 
Vv 
2 6 8 7 1 
size 
5 temp | +35 























To insert this node into the list, we first need to set the new node’s pointer field to point to 
the same node that the current node’s pointer field points to. 




































































head current 
Vv 
2 6 8 7 1 
size i 
5 temp | +> 























Then, we need to set the current node’s pointer field to point to the new node. Note that this 
cannot take place before the previous step. If we write over the address stored in current->next 
before saving that address (the address of the node containing “7”) inside temp->next, then we 
lose the address completey...and therefore can no longer reach the rest of the list! The ending 
chain of the list, starting with the node containing “7”, would be floating off by itself and would 
be unreachable since we would not have the address of the node containing “7” stored anywhere. 
So, you have to save its address in the new node before overwriting it in the old node. 

































































head current 
V 
2 6 8 7/73 1 
size / 
5 temp | +> 























And finally, we write the new value into the new node. In addition, since we want the just- 
inserted node to be the “current” node, it is necessary to move current to point to the new 
node. Also, we want to increase the value held in size by 1. 
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head 
v 
2 6 8 7T\|7 > 1 
size / 
-» 6 temp | +3 9 <———current 














What about InsertBefore(9)? Well, allocating the new node can work the same way, but 
then we have a problem. Before, we wanted to set the pointer of the node containing “8” to 
point to the new node. Now, if we are instead inserting before that node, we instead need to set 
the pointer of the node containing “6” to point to the new node. So, what is the problem? Well, 
we had easy access to the node containing “8”, since current pointed to that node. But the 
only way we can get the address of the node containing “6” is to traverse the entire list, from 
the beginning, until we are at the “node before current”. That is, we could use the following 
code: 


Node* prev; 

prev = head; 

while (prev->next != current) 
prev = prev->next; 


to position a pointer called prev at the node right before current. Then, we can insert the new 
node after the node pointed to by prev, the same way we inserted such a node after the node 
pointed to by current for InsertAfter (9). 





head prev current 
\ v 
2 6 8 sh 1 
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However, this will potentially take a lot of time. If this is a very long list, and current is 
pointing to a node near the end of the list, our traversal code above will need to traverse over 
nearly every node in the list in order to place prev pointing to the node before current. It 
would be nice if we could implement InsertBefore(X) without needing to take this expense. 

And, in fact, we can! The secret to speeding up this operation lies in thinking in terms of the 
ADT rather than the implementation. And that secret is this: As long as the abstract picture 
looks correct, we don’t care what happened with the implementation! As long as, at the end of 
our operation, we can traverse down the list and read: 2, 6, 9, 8, 7, 1, that is all we need. 

How does this help? Well, it means that we do not necessarily need to insert the new node 
before the current one — just that eventually, the new value needs to be before the current one. 
So, why not perform an InsertAfter(), which we already know we can do quickly, and then 
switch the new and current values? 

In the figure below, rather than perform the last step of InsertAfter() (namely, writing the 
new value in the new node and moving the current pointer to point to the new node), instead 
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head current 

V 

2 6 &9 7T/7> 1 
size i / 

cs temp | +> 8 

6 


Figure 1.3: Completion of alternate InsertBefore (X) 


we have written the current value in the new node, and then overwritten the value in the current 
node with the new value. This places the values in the exact order in which we want them! In 
addition, current doesn’t need to be moved; it is already pointing to the node with the new 
value. The reason this solution works is because we don’t care if we are really inserting the new 
node after the current one, as long as the new value eventually ends up in the node just prior to 
the current value. In the figure above, the resultant “abstract picture” it represents is exactly 
the same as the one we’d get if we had actually inserted the new node before the (then) current 
one. All that is different is the order of the memory addresses of the nodes as you read down 
the list from head to end, and that detail is entirely irrelevant to supporting the ADT correctly. 
So, we can use this solution and save ourselves the traversal time we would otherwise need to 
point prev to the node prior to current. 

As a result, we can perform any insertion into a linked list in O(1) time. 

Basing the remaining discussion examples off of the list generated by the InsertAfter (X) 
call, it should be clear by now how to handle the IncrementCurrent () function — simply move 
current to the next node in the list: 


head 
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temp | +> 9 current 

















Figure 1.4: Moving the current pointer forward one node 


Next, what about Remove()? Well, with this function, we have the same situation we 
encountered with InsertBefore(X), namely that at first glance it seems that we need to traverse 
the entire list to get a pointer to the node before the current one. After all, if we are going to 
remove the node containing “7” from the figure above, that means we need to point the “next” 
field of the node containing “9” to the node containing “1”, so that the node containing “7” is 
cut out of the list, as in the following diagram: 
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head 
















































































current 
v 
2 6 8 ya ache | 
RA A 
! 
temp | +> 9 ask fos 256 
prev (Traverse this pointer down the list 


until it points to the node before 
current. This way, we have access to 
the pointer field of the node before 
current.) 


Figure 1.5: Cutting a node out of the list 


Fortunately, just as with InsertBefore(X), it is not necessary to traverse down the entire 
list just to reach the node before current. Instead, we will again take advantage of the fact 
that we can manipulate the implementation however we like as long as the abstract picture is 
correct in the end. Specifically, to remove the current value, you simply delete the node after 
the current node, and copy the value of the deleted node into the current node. 


head current 
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Point to next node 
(here it is NULL, but 
in general it will be 
an actual node). 
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Figure 1.6: Remove the successor, and copy the successor’s value 


The only time this would not work would be if the node to be deleted was the end node. In 
this case, there 1s no successor node to “delete instead”. So, one way around this problem is to 
just code Remove() to treat that as a special case — in which case that one situation will require 
an expensive traversal down the list, while the other removal situations can be handled without 
such a traversal. A second way around this problem is to again use the dummy node idea. This 
time, the dummy node would be at the end of the list, and as a result of it being there, there 
would always be a successor node, and thus there would always be a node you could “delete 
instead”. However, this results in the same problems that the dummy node creates if it is at the 
front of the list. So, we are going to settle for having this one case take longer than the others. 
(We’ll see a nicer solution to this problem shortly.) 

For Find(X), just as with the contiguous implementation, we are forced to potentially search 
every node in the list trying to find our value. This is best done as it was with the contiguous 
implementation, namely, by starting a traversal variable (there, an index; here, a pointer) at the 
beginning of the List, and moving it forward a value at a time until we either find our value or 
reach the end of the List. 
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int Find(X) 


s: 


// start pointer at beginning of list 
Node* tempPtr = head; 


// move forward as long as 

// a) not at end of list, and 

// b) current element is not X 

while ((tempPtr!=NULL) && (tempPtr->element != x)) 
tempPtr = tempPtr->next; 


// if we are at the end of the list, we have 
// not found the element 
if (tempPtr == NULL) 

return 0; 


// if tempPtr is not at end of list, it 


ie can only be because the value was 
// found before the end of the list 
// was reached 

else 

{ 


current = tempPtr; 
return 1; 


One other interesting operation to consider is Tail(). As our list exists now, the only way 


to get our current pointer to point to the last node of the list is to simply start moving it 
forward node-by-node until the next node is NULL rather than a real node. This, of course, 
might potentially require a traversal all the way down the list. We can make this a much faster 
operation simply by having an extra pointer as part of our List implementation. In addition 
to having head and current, we can have tail, which will always point to the last node of the 
list. 



























































head tail 
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_size 
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Figure 1.7: The tail pointer 


Now, to point current to the last node of the list, we simply set current equal to tail (ie. 


current = tail;). 
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There is a slight performance slowdown to this method — not in Tail(), but in some of the 
other functions. Every time we insert as the last node, remove the last node, or copy the list, it 
will now be necessary to check the tail pointer as well, and make sure it is still pointing to the 
right spot. However, this is just a constant-time increase in the running time for those functions, 
and as a result, is not all that serious (in most cases). 

The remaining ADT operations proceed in much the same way as the operations above, and 
we won’t go into further detail here. 


Analysis of linked memory lists 


Just as with the contiguous implementation, we basically have two choices for the running 
times of the linked implementation operations: O(1) or O(n). However, the speed up comes in 
different places for the linked implementation. For example, the insertion operations are simply 
a series of memory allocations and pointer assingments...and that totals to constant time. So, 
while InsertBefore() and InsertAfter() were O(n) for the contiguous representation, they 
are O(1) for the linked implementation. 

In addition, Remove() is also O(1), at least except for deletion of the last node. Again, this 
is because you are only doing a few pointer manipulations and some assignments. However, 
deletion of the last node will require traversal down the list to find the node prior to the current 
one. In this case, you read every node but the last one as you traverse, so as a result, removal 
from the end of a list is O(n). 

Find(X), of course, will need to traverse the entire list in the worst case, and this is O(n) as 
well. 

Other than that, the only function (other than the creation/destruction/mass edit functions) 
that is not constant time is DecrementCurrent(), which needs to traverse down the list to find 
the node previous to the current one, and thus is O(n). The Tail() function is constant time 
only if the list has a tail pointer; if not, then Tail() needs to perform a traversal down the 
list and is thus O(n). 


1.3.3. Doubly-linked lists 


Having to traverse down the list every time we want to reach the node prior to the current one 
is somewhat annoying and is something we’d want to avoid, if possible. However, the only way 
to avoid it is to be able to detect, in constant time, where the prior node is located. The easiest 
way to do this is to use two pointers in a node: one to point to the next node, and one to point 
to the previous node. 





prev | element next 

















prev: name of pointer field pointing to previous node 
element: name of field that stores our value 


next: name of pointer field pointing to next node 


Figure 1.8: The doubly-linked list node 
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By chaining nodes of this type together, we are able to traverse forward and backward across 
the list. 




































































head current tail 
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Figure 1.9: Cutting a node out of the list 


Right away, this gives us two improvements. First, DecrementCurrent() can now run in 
O(1) for lists, because we can access the prior node in constant time. Second, Remove() can now 
run in constant time even if we are removing the last node of a list. This is for the same reason 
— if we need to set the pointer of the node prior to the current one (the one being removed), 
having constant time access to that prior node gives us the means to change that pointer in 
constant time. 

However, we take a space and time hit for this implementation, as well. Each operation that 
needs to manipulate the list elements takes a little longer now, because there are two pointers 
per node to worry about. This extra time is simply some extra constant time, so the order of 
growth of the operation running times doesn’t change, but if you count constant factors, some 
of the operations will take slightly longer. In addition, we are using O(n) extra memory — one 
extra pointer per value. In practice, though, these tend to not be critical details, since the 
amount of time and memory added is so small. 

It is also necessary to be a little more careful when you code your operations, since now you 
are dealing with two pointers and so some situations become more complex as a result. For 
example, imagine we are ready to insert a node into a doubly linked list (using InsertAfter, 
as below: 










































































head current tail 
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Attaching the new node to the list is the straightforward part: 


temp->next = current—>next ; 
temp->prev = current; 
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head current tail 
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However, the next steps must be done in the right order: 


current—>next—>prev 


= temp; 


head current 


tail 
y | 
2 6 
size 
5 
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...and then: 


current—>next = temp; 


head current 


tail 
Vv 
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If you reverse the two statements above, then current->next gets changed before it is read, 


and so the value we think we are reading is therefore not correct. What we will get instead, if 
we reverse these two statements, is the following picture: 
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What happens here is that when you try and run: 
current—>next->prev = temp; 


current—>next has been changed already, and so you end up taking temp’s prev and setting it 
to point to temp. What can be the most maddening thing about this error is that it is so hard 
to detect; traversing the list in a forward manner still works fine. So, you could be using the list, 
and getting everything to work exactly the way you want it, simply because you are traversing 
foward...and the instant you try and traverse backwards from a particular node, you suddenly 
are hitting an infinite loop on a list that has “worked beautifully” up to this point. The lesson? 
the more complexity your code has, the more careful you need to be. 


1.4 Comparison of the three implementations 


The table below summarizes the running times of the List ADT operations on the three imple- 
mentations we looked at. Note that the creation/destruction/mass edit functions are included 
here, too. Certainly, creating an empty list would take O(1) anywhere, and copying — whether 
by an operator= function or via a copy constructor — would naturally take O(n) time since you 
need to read each element in order to copy it. However, there are differences between the imple- 
mentations when you consider destruction and clearing. With the contiguous implementation, 
the array is all one chunk of memory, and so it can be deleted in constant time. However, for 
the two lists, it is necessary to traverse down the list, node-by-node, deleting individual nodes 
as you go. So, deletion and clearing for the linked list implementations will take O(n). 
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Operation Contiguous | Singly-linked | Doubly-linked 
Constructor O(1) O(1) O(1) 
Copy Constructor O(n) O(n) O(n) 
Destructor O(1) O(n) O(n) 
operator= O(n) O(n) O(n) 
Clear () O(1) O(n) O(n) 
InsertAfter (X) O(n) O(1) O(1) 
InsertBef ore (X) O(n) O(1) O(1) 
Remove () O(n) OUn)* O(1) 
Update (X) O(1) O(1) O(1) 
Find (X) O(n) O(n) O(n) 
Length () O(1) O(1) O(1) 
Retrieve() O(1) O(1) O(1) 
IncrementCurrent () O(1) O(1) O(1) 
DecrementCurrent () O(1) O(n) O(1) 
Head() O(1) O(1) O(1) 
Tail( O(1) OC) OC) 
* O(n) for removal at end of list 
** Assumes tail pointer; O(n) if there isn’t one 








